Splitting out downloadTestRepo does mitigate the problem, but the underlying question remains why "example.thirdparty[gatling].testRepoRoot" seems to be an invalidation root when neither of its upstream tasks changed and it itself is not a source or input task

The problem appears to come from the fact that the preparatory input evaluation done in selective execution uses a subset of the tasks, resulting in the inputs being labelled differently during planning, such that the overridden example.thirdparty[gatling].testRepoRoot in the preparatory evaluation has the same label as the overridingexample.thirdparty[gatling].testRepoRoot in the main evaluation. This causes them to collide on disk and results in the latter unnecessarily invalidating since the hashes appear to have changed (since the other task stomped over the json files on disk)

This whole "tasks are assigned their final label during planning" thing is an endless source of bugs, and was originally introduced because we started using the ordering of tasks during planning to determine override ordering which is necessary to assign .super.Foo suffixes as part of the labels.

We probably should try to detect move override detection and label allocation to task instantiation time to avoid this footgun.